BBS Toolkit/BBS Toolkit.iso/doors_2/wwnet32.zip/WWIVNET.DOC

Text File | 1993-04-01 | 103KB | 2,208 lines

                                 WWIVnet Docs

                                    v2.32

                                      by



                                Wig De Moville

                                    <aka>

                                     Filo
















                               October 15, 1992









                         WWIVnet Documentation v2.32

                              Table of Contents


  1. HISTORY  . . . . . . . . . . . . . . . . . . . . . . . .     4

  2. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . .     4

  3. REGISTRATION . . . . . . . . . . . . . . . . . . . . . .     5

  4. ORGANIZATION . . . . . . . . . . . . . . . . . . . . . .     6
4.1. Group Coordinator . . . . . . . . . . . . .. . . . . . .     6
4.2. Area Coordinator  . . . . . . . .. . . . . . . . . . . .     7

  5. RULES AND REGULATIONS  . . . . . . . . . . . . . . . . .     8
5.1. Requirements for GC . . . . . . . . . . . .. . . . . . .     8
5.2. Requirements for AC . . . . . . .. . . . . . . . . . . .     9
5.3. Long Distance Connections. . . . . . . . . . . . . . . .    11
5.4. Providing MoreService  . . . . . . . . . . . . . . . . .    11
5.5. Dissatisfaction with AC . . . . . . . . . . . . . . . . .   12
5.6. Sysops  . . . . . . . . . . . . . . . . . . . . . . . . .   12

  6. INSTALLATION . . . . . . . . . . . . . . . . . . . . . .    14
6.1. Apply for Network Node Number . . . . . . .. . . . . . .    14
6.2. Being Checked Out . . . . . . . .. . . . . . . . . . . .    15
6.3. Node Number Assigned  .. . . . . . . . . . . . . . . . .    15
6.4. CALLOUT.NET .. . . . . . . . . . . . . . . . . . . . . .    16
6.4.1. Macros .. . . . . . . . . . . . . . . . . . . . . . . .   16
6.4.2. Transmit Options . . . . . . . . . . . . . . . . . . .    16
6.4.3. Callout options  . . . . . . . . . . . . . . . . . . .    17
6.4.4. Passwords  . . . . . .. . . . . . . .. . . . . . . . .    18
6.5. Network Software  . . . . . .. . . . . . . . . . . . . .    18
6.6. Waiting and Patience . . . . . . . . . . . . . . . . . .    19
6.7. The AreaCoordinator (AC) . . . . . . . . . . . . . . . .    20
6.8. The Group Coordinator (GC)  . . . . . . . . . . . . . .     20
6.9. Net Editor  . . . . . . . . . . . . . . . . . . . . . .     21

  7. USING THE NETWORK  . . . . . . . . . . . . . . . . . . .    21
7.1. Sending Netmail . . . . . . . . . . . . . .. . . . . . .    21
7.2. Subscribing to a Netted Sub . . .. . . . . . . . . . . .    22
7.3. Hosting a Netted Sub  .. . . . . . . . . . . . . . . . .    24

  8. NETWORK FILES  . . . .  . . . . . . . . . . . . . . . .     25

  9. TROUBLE-SHOOTING NETWORK CONNECTIONS . . . . . . . . . .    26
9.1. You force callout and the cursor returns to WFC  . . . .    27
9.2. Your board calls out and gets a "Bad PW" message . . . .    27
9.3. Your board calls andgets a "NO NET" message  . . . . . .    27

  10. FUTURE DIRECTIONS . . . . . . . . . . . . . . . . . . .    28

  11. APPENDICES  . . . . . . . . . . . . . . . . . . . . . .    29
11.1. Appendix A - PcPursuit Macro . . . . . . .. . . . . . .    29
11.2. Appendix B - Network message types. . . . . . . . . . .    30
11.3. Appendix C - Network Policy for Illegal Activities .  .    31
11.4. Appendix D - Identifiers Used in BBSLIST . . . .  . . .    32
11.5. Appendix E - Suggestions for Smooth Networking .. . . .    33
11.6. Appendix F - Using the Net Software for Private Networks   34
11.7. Appendix G - The Process of Becoming a Group Coordinator   35
11.8. Appendix H - Procedure for Joining/Leaving WWIVnet:  . .   35
11.9. Appendix I - Automated subboard requests . . . . . . . .   36
11.10 Appendix J - Multi-networking. . . . . . . . . . . . . .   37
11.11 Appendix K - Optimizing HS/LINK for WWIV & Net . . . . .   37

  1. HISTORY

       The first version of WWIVnet Docs was written by Will
Daystrom, also known as The Captain (1 @2370), who ran the White
Star Line and who copyrighted the Documentation for WWIV v4.10
and WWIVnet Docs under White Star Line Software.  His documentation
was excellent and would not have needed to be rewritten if WWIVnet
were not a dynamic organism, changing as the needs of the network
change.

       This version of the WWIVnet Docs is written by Filo (1
@5252), and is deliberately not copyrighted in order that future
versions can be built upon it without anyone's having to worry
about copyright infringements.  If additional changes in the
documentation are necessary, I will offer them as v2.x if I am
still involved with WWIVnet.  If I am not, then the next author can
decide whether to continue with 2.x or change to v3.x.  I think
that 3.x should be reserved for a major change in the working of
WWIVnet such as is taking place under the current network
reorganization.

       This version of the WWIVnet documentation has been written
from scratch while maintaining the basic organizational structure
begun by Will.  In this document, however, you will find a great deal of
information obtained from Wayne Bell, the author of the WWIVnet
software and the WWIV Bulletin Board System.



  2. INTRODUCTION

       WWIVnet is a voluntary association of bulletin boards using
WWIV software and participating in a network by calling one
another to facilitate the transfer of electronic mail (email) and
message bases (subs).  At the current time, WWIVnet is the second
largest network running on private computers in the United States.
It has over 1000 systems located in the United States, Canada,
England, W. Germany, Italy, Mexico and Japan.

       Through this network, a user of any of the bulletin boards
that are   members may send email to a user of any other board.  A
user may also post on a message base which may be read by the users
of systems which subscribe to that message base; thus, many of the
networked subs have international distribution.  Because this
system of communication is read by others and because it has an
effect on systems other than the one on which it originates, a
spirit of cooperation must prevail.  Out of this spirit grows a
system of organization and regulation which are discussed in the
pages that follow.
       The first part of this document addresses the WWIVnet
organization.    The second part deals with rules, regulations, and
suggestions which have developed over time for WWIVnet.  The third
segment explains how a sysop may install WWIVnet upon his system
and it deals with the roles of the Area Coordinator (AC) and the
Group Coordinator (GC).  The fourth section explains how a sysop
may subscribe to message bases, host message bases, and how users
may send messages to another system.  The fifth section provides an
explanation for each of the programs involved in the network
software and the associated files.  The fifth section also offers
some advice regarding debugging network connections.  The sixth
section speaks briefly of developments which we may see in the near
future.

  WARNING: When you unzip the network software, you should see "-
AV" on the line next to every filename.  Furthermore, after the
files have been   extracted, you should see the message:

  Authentic files Verified!   # XLD658   WWIV Software Services

  If you do not see the "-AV" and the above message (be sure the
number is   "XLD658"), then the files you have have been tampered
with, and you should not use them.  Since this software is used by
several WWIV-based networks, the files herein should not be
extracted and included in another network package.  If you desire
to distribute NETxx with another network software, you should
include the NETxx.ZIP file in its entirety within the other network
archive in order to preserve the AV codes.


  3. REGISTRATION

  Up until net28, the WWIVnet software has been distributed freely
to   everyone.  Starting with net28, the net software is
distributed much like the WWIV software itself.

  The WWIV and WWIVnet software is distributed as shareware, which
means   (in this case) that you can use the WWIV and WWIVnet
software for up to two months before deciding whether or not to
register WWIV.  If, at the end of the two month period, you decide
to register WWIV, please see the 'read.me' file in the WWIV .ZIP
file for information on how to register.   If at the end of two
months you decide NOT to register WWIV (and hence not use WWIV
software for your BBS), you must stop using the WWIV and WWIVnet
software.

  If/when you register WWIV (and receive a WWIV registration
number), you   have also registered the WWIVnet software, and may
use the WWIV and WWIV   software on your system as you wish -- as
a standalone BBS, in WWIVnet, or in a private network.
  If you are running a BBS that is in no way based on WWIV
software, but   that uses the WWIVnet software, then a similar
registration procedure   applies.  You can use the WWIVnet software
for a two month trial period.   If you decide to continue using the
WWIVnet software after the two month trial period, then you must
register the WWIVnet software for $20.  If you do not register the
WWIVnet software at the end of the two month trial period, you must
stop using the WWIVnet software.

  Thus, there are two ways you can legally continue to use the
WWIVnet   software after the two month trial period.  Either
register WWIV, or (if   you are running BBS software that is in no
way based on WWIV software),   register the WWIVnet software for
$20.

  If you are using BBS software that is in no way based on WWIV
software,   and wish to use the WWIVnet software, please use the
form 'netreg.frm' to register the WWIVnet software.



  4. ORGANIZATION

       WWIVnet originally began in 1988 with 25 charter members who
helped   Wayne Bell develop the network software and debug it.
Since that time it has spread from a small Los Angeles-based system
of local boards to an international network.  Currently, the
network software is in its 32nd version although there will
undoubtedly be many future versions written as well.  These
versions are referred to as Net1, Net2,...Net20, etc.  The
international network has Wayne Bell as its head.  The network is
organized into groups with each group having a Group Coordinator.
Currently there are 14 groups.  Each group is composed of
approximately 100 systems which may be located in one or more area
codes.  Each area code where there are more than 5 network systems
has its own Area Coordinator.

       For those area that have fewer than 5 systems, the Group
Coordinator functions as the area coordinator for the small area
code.

       An understanding of the roles of the Group Coordinator and
Area Coordinator facilitates cooperation and prevents arguments
and disputes.    The rules, regulations and suggestions which are
presented here are designed to insure that the network functions
well and that friction between the components of WWIVnet does not
develop.

       However, these rules should not be forced to apply to
situations   where they do not seem to logically fit.  Instead, the
rules can be adapted to the situation.  These rules should not be
regarded as "carved in stone," for WWIVnet is dynamic and
undergoing evolutionary changes as it grows.  These documents will
be revised from time to time to reflect these changes.

  4.1. Group Coordinator

       The group coordinator is a position developed by Wayne in
response   to growth in the network and suggestions of many
interested parties.  The network growth necessitated a division of
duties so that the updating of the network could occur in smaller
packages; that is, there was up through NET19 a natural limit of
32k to the length of BBSLIST.NET.  As the number of systems grew
and the length of the file approached its natural limit, Wayne was
faced with the decision of either developing a new organizational
structure or telling network members that no new systems could be
added.  For obvious reasons, the first alternative was selected.

       In addition to serving as the Area Coordinator for area
codes where there are five or fewer systems, the Group
Coordinator has the following duties:

       1)   Receive from AC's and forward to Wayne Bell updates to
the BBSLIST.NET (i.e., information on systems being added to the network).
Plans have been made to allow distribution to group members directly from
the GC but this is not taking place yet.

       2)   Send out CONNECT.NET entries to the member systems of
the group.  The current files, called CONNECT.0 to CONNECT.14, are
distributed by Wayne Bell, the Net Coordinator (NC), but in the future the
CONNECT file for each group may also be distributed to the members of a
group by the GC.

       3)   Help determine the best routing for out-of-group
messages.

       4)   Help to insure that no system or group of systems
becomes isolated (i.e., without a connection to the outside
world).

       5)   Serve as first step in grievances between sysops and
their Area Coordinators and in other disputes.  The final step is to have
Wayne Bell resolve the problem.

       6)   Facilitate the election process when Area Codes hold AC
elections.

       7)  Check WWIV and WWIVnet registrations to insure that new
nodes have complied with the 60-day trial period requirements.


       The duties listed above are discussed indirectly in more
detail in connection with the technical working of the network.


  4.2. Area Coordinator
       The duties of an Area Coordinator are simple and few;
however, these activities are extremely important for the proper
functioning of WWIVnet.  The duties are as follows:

       1)   Investigate net applicants and either assign them a
node number or provide them with a reason why no node number is being
assigned.  This function is discussed more thoroughly under rules and
regulations below.
       2)   Forward the information to the Group Coordinator.
       3)   Process changes, new connection requests, etc., for
sysops in the area code.

       These duties and other services that might be rendered by an
area coordinator are further discussed in the section on rules
and regulations and in the section on the technical working of the
network.

  5. RULES AND REGULATIONS

       WWIVnet is characterized by very few rules and regulations.
Those that do exist are either absolutely necessary to the proper
functioning of the network or are common courtesies that should be
extended between cooperating systems.  I will use rule and
regulation interchangeably in the discussion which follows.  There
is no difference between the terms as used here.  I have done my
best to organize these rules in terms of whom they apply to.  Since
every AC or GC is also a Sysop, the rules for Sysops apply equally
to the AC's and GC'S.


  5.1. Requirements for GC

       The person serving as GC was either (a) nominated by Wayne
Bell or   someone else such as an AC or (b) self nominated due to
the connections   maintained.  The individual has been accepted by
Wayne, by the AC's with   whom he/she must relate, and possibly by
a vote of the sysops in the area as well.  However, the process of
becoming a GC is NOT necessarily a democratic one.  That is, being
a Group Coordinator is not the result of a popularity contest;
instead, it is the result of demonstrated maturity in the network,
willingness to serve, and having the confidence of the AC's and
Wayne Bell.  Such an individual should be mature (not necessarily
old), easy to get along with, prompt in answering to the needs of
others, and be willing to devote time to insuring that the group is
well represented.  [Side Note: The he/she construction above seems
to be unnecessarily awkward; therefore, where the use of a pronoun
seems appropriate, I shall use either he or she; however, the
context should make the pronoun's referent clear.  The gender of
the person(s) referred to does not really matter.]

       The Group Coordinator should agree to the following
conditions:

       1)   She will serve as long as she maintains the confidence
of those being served and as long as she is willing. However, this period
of service should be a minimum of three months, and she must provide at
least 3 weeks notice before stepping down from the position.

       2)   He will maintain contact with the AC's and Sysops
within the area in order to insure that (a) all boards are
receiving net messages and net updates, (b) no board or group of
boards becomes cut-off from the rest of the network.

       3)   She will listen to both sides of any disagreement and
promote communication between the parties involved in the
dispute.  She will render an impartial recommendation based upon
the facts and inform Wayne Bell of the dispute and recommended
resolution in those instances where it appears that people may have
strong and/or hurt feelings.  This role calls for some maturity and
judgement.  Wayne should not be informed or bothered with the settlement of
a dispute regarding a trivial matter, but he should be informed about all
disputes which might have an unsettling effect upon the network.

       4)   Promptness, Accuracy, Honesty, and Communications
should be the qualities promoted by the Group Coordinator.
The workings of the group (actually a mini-network) depend upon the
Group Coordinator's being prompt in his responses, accurate in her
work, honest in his dealings with others, and demonstrative of a
willingness to communicate in an open and frank manner but  with
tact where it is called for.

       5)   He will appoint an Emergency or Assistant GC.  The
identity of the appointee will be made known to the NC.  The
assistant should obtain an account on Amber (the NC's board).  If
an emergency situation should arise or the GC go on an extended
vacation, then the Assistant could be given access to the GC
software and make network updates until the GC is able to return to
his position.  The Assistant is NOT automatically in line for the
GC position.  He might or might not be appointed as GC in the event
that a replacement situation evolved.

       The role of Group Coordinator may evolve in the future to
take on additional responsibilities and there may be additional
requirements.


  5.2. Requirements for AC

       Prerequisites to be an Area Coordinator.  To be an area
coordinator, you must meet the following criteria:

       1)   Be currently running a system 24 hours a day.
       2)   Promise to run the system for at least 3 months into
the         future.
       3)   Promise to notify the GC at least 2 weeks in advance of
taking down your system, and suggest a new coordinator for your
area if/when you do.
       4)   Be willing to put in some time to get the net up and keep it
going.
       5)   Be willing to rack up some LD charges, or know someone
in your   area who is.
(WWIVnet Guide by Will Daystrom (c) White Starline Software)


       If there is no AC in your area, you may confer with your GC
who will help the boards in your area (once there are more than
five) obtain an AC.  Currently several methods exist in WWIVnet for
the establishment of an AC in an area where there is none or where
the previous AC left without recommending a replacement.  These
methods include: (1) nomination of an AC by the GC and
ratification/refusal by the sysops in the area code; (2) nomination
of an AC by the sysops in the area code and ratification or refusal
by the GC.  In any case, once an AC has been  chosen for the area,
Wayne Bell must still approve that person's acting as AC.

       It should be obvious from the guidelines in this manual,
that the AC performs a valuable but somewhat thankless function and
that there is no power associated with the position.  Therefore, to
attempt a coup in order to become AC would be somewhat meaningless.  If an
AC has power,  it is because area boards have permitted the person to have
power, NOT because the AC position is powerful.


       If the number of boards in an area that has an AC drops
below five,   the AC continues to function.  The GC does not take
over the responsibilities of AC unless the AC resigns.  In that
event, if there are fewer than five boards remaining in the area,
the GC may fulfill the AC's duties until growth brings the number
of systems to six or more.


       "There is one (and only one) coordinator per area code, and
      is/her primary duties are to assign net numbers to new
systems joining the net, accept and check out connection info supplied
by systems within their area code, and to forward this information
(connection and bbs info changes) to @1."
(WWIVnet Guide by Will Daystrom, (c) 1989 White Star Line Software)

       The quote above taken from WWIVnet Guide summarizes the
primary duties of an AC very well.  The only change in the
description is that now the information is forwarded to the GC who
in turn forwards it to 1 @1.   As an AC you must assign net numbers
to new systems that want to join the net.  Before assigning the
node number, you should establish that the board is a viable board.
Basically this means that you must feel relatively confident that
the applicant will continue to run for a few months.  This is
necessary in order to insure stability for the network.  This
information, of course, must be forwarded to the GC.


       In addition to that primary duty, the WWIVnet Guide
indicates that the area coordinator may under certain circumstances deny a
network node number to a board.  This should only be done in circumstances
which are well-defined.

       These are: (1) if the AC has doubts about the stability of
the board, or (2) the AC has a policy that no part-time boards
will be permitted in the network.

       In the first case, the AC should inform the sysop that he
needs to be running for a specified period before a network
connection is established.  If at that point, there are still
concerns about the board's stability, the board could be assigned
a node number and limited to one connection.  The key thing here
is communication with the applicant.  Be certain that the sysop
understands why he cannot get a node number immediately, that he is
aware of when he will be assigned one and under what conditions.

       In the second case, the AC may deny access to the network on
a more permanent basis, but again, communication is the key to
handling the situation.  Before adopting a policy the AC would be
well-advised to discuss it with the GC and with the WWIVnet Sysops of the
area code.

       If an AC decides to have a policy regarding a waiting period to get
on WWIVnet, that period should NOT exceed one week.


  5.3. Long Distance Connections

       It is NOT the AC's responsibility to establish long distance
connections for the boards in the area code.  That responsibility
belongs to the sysop of each board.  In many cases, however,
several   boards will use the long distance connections of one
board which acts as a hub and which does most of the long distance
polling.  In that event, the long distance connection may limit the
numbers of subs or mail sent by those which connect to him.  Note
that this is a function of the long distance connection and not a
function of the AC (even if both are the same person).

       As AC you may suggest that certain boards might wish to help
another with long distance charges and so forth but remember that
this is purely voluntary.  Also you should remember that you do not
have the power to prohibit a person from making long distance
connections or from taking certain subs.  A sysop may make whatever
long distance connections that he feels that he can afford and may
carry any subs that he is willing to pay the long distance bill
for.  In cases where one board makes the long distance connections
to obtain subs for others, the sysop of the board making the calls
may limit the traffic, but that is him functioning as long distance
connector not as AC.


       Further, the AC is not expected to provide technical advice
regarding WWIVnet.  It is nice if he can do so, but it is not part
of the "job description."  There are WWIV SUPPORT BOARDS which
should be able to provide such advice if it is necessary.


  5.4. Providing More Service

       An AC may choose to provide additional services to the area.  For
example, the AC may be instrumental in organizing meetings of
local and/or area sysops and may help to organize the area for more
effect long distance connections; however, this is not part of his
function as an AC and should not be considered as part of the AC's
authority.  Any arrangements of this kind are accepted by area
boards because they voluntarily choose to do so.

       They (the area boards) may at any time choose to do things
differently and it should not affect the AC's duties.  Thus, a word
of   caution to the AC, DO NOT BECOME EGO-INVOLVED in additional
services and/or organizations.  That is, always be certain that all
understand that those activities are not part of your AC duties and
that you can function as AC regardless of what transpires in the
other circumstances.


  5.5. Dissatisfaction with AC

       If you are dissatisfied with the performance of your AC, you
should   first discuss the matter with the AC.  It may be that the
AC has tired of his duties, is experiencing problems that you are
unaware of, or is actually doing better than you know.  In any
case, the first step is to discuss the matter with the AC.  If it
cannot be resolved in this fashion, then you should make the GC
aware of the problem.  The GC should then check the matter with the
AC.  If you have not made the AC aware of your concerns, that fact
will come to light at that time.

       Through a process of communication among sysops, AC, and GC
it is   hoped that the matter can be resolved.  If not, the GC will
discuss the   matter with Wayne Bell who will have the final say in
the matter.    Communication, cooperation, and respect for one
another are the keys to the successful resolution of problems.

       At the current time, there is no established procedure for
the   removal of an AC or a GC.  Each case, if it occurs, is
handled on a case-by-case basis by Wayne Bell.  Discussions are
underway regarding such procedures, so it is possible that a
process will be adopted soon.


  5.6. Sysops

       Sysops who decide to participate in WWIVnet should be aware
that   each host of a network sub has the right to insist upon her
own rules, and she may delete any subscribing board that she wishes
from the list of subscribers.  If the subscribing sysop does not
like this, the only   recourse is to start your own sub and/or
convince the host to change her   mind.  This is not an appropriate
matter to raise with your AC, your GC, or Wayne Bell.  In this
matter the host is Queen or King as the case may be.

       A Sysop should notify the host of any subs that he wishes to
subscribe to and ask to be put on the distribution list for that
sub.    Doing so, means that the sysop is willing to adhere to the
rules of that   sub.  If the sysop later decides that he no longer
wishes to take that sub, he should notify the host system.  Failure
to notify the host system will result in that sub being sent to the
subscriber anyway.  Thus needless long distance costs are incurred
by the systems carrying the mail.  Notifying the host of a desire
to be dropped from a sub should be through netmail and not by a
post on the sub.

        WWIV v4.20e and up supports the automatic request for a sub
and the automatic removal provided that each board has the network
software to support the feature and provided that the sysop has
configured his board to allow auto-requests.  Beginning with NET32,
the automatic request feature and an option for the description of
the sub in the SUBS.LST is included in BOARDEDIT.  This feature
should facilitate a board's adding or dropping subs that are
subscribed to.

       The network software includes the creation of informational
files on each network system which reflects subs or messages
received that have 'no place to go.'  In effect that would mean
that the receiving sysop has not created a message base for that
sub or has deleted it but is still receiving mail for it.  The
sysop should check this file regularly and if he is receiving subs
that he has not ordered or does not want, he should notify the
sending host to please remove his system from the distribution
list.  This information and other information on network
connections may be found in your GFILES directory in files named
NETDAT0.LOG, NETDAT1.LOG and NETDAT2.LOG.  The NETDAT0 is the
newest log and NETDAT2 is the oldest log.  These logs are only kept
for a three day period unless you make other provisions to have
them saved.  They may provide useful information to you in terms of
what you are/are not receiving and in terms of problems that may
occur in your network connection.

       The sysop should also occasionally review his DEAD.NET file
which   will be in DATA.  Messages in this file are those which
were bound for another system but which cannot be delivered after
having arrived on your system.  Often these are due to one of two
factors.  The first case might be due to a board's having
subscribed to a sub and having been put on the distribution list
for it before that board has been added to the bbslist.  Thus the
system does not know where to deliver it.  If that is the case, the
DEAD.NET should be left alone because once the system is added, the
network software will deliver that mail to the new system.    The
second case would occur when a board has left the network or has
been temporarily disconnected from the network.  It may still be
receiving mail because either the sysop failed to notify the host,
mail was already in the system, or because the host sysop has
failed to remove the board from the distribution list.  In that
case, the mail may be safely deleted.  Before deleting the mail,
you should check with the board's AC to be sure that the board is
out of the network.

       In addition, the sysop should write the host of the sub
whose mail   is going to DEAD.NET and inform the host of which
board is no longer on the network and request that host delete the
board from the distribution list. NET32 and up also has a feature
to report on undeliverable e-mail to another system in the form of
a System Short Message.

       Sysops who receive subs from other systems have the
responsibility   to restrict access to the sub according to the
rules of the host.  For   example, some subs may limit access to
User Number 1, to users with 255   access, or some other
requirements such as all posts must not have tag   lines.  The
receiving sysop must also take steps to inform users of the   rules
applying to a particular sub.  GFILES are often a good way of doing
this.

       These guidelines for sysops are nothing more than common
sense and   normal courtesy which reflect the desire on the part of
all to cooperate in order to make the network work properly and
efficiently.  One of the   interesting features of the network is
that it is a great leveler.  No one (except possibly a few sysops)
knows the age of the person making the post; therefore, people's
impressions of the person who posts is made entirely based upon the
language used and the thought expressed.  As a consequence many a
young user can convey the impression that he is much older and more
mature, and some older users may convey the impression that they
are irresponsible, illiterate users.  One hopes that users will opt
to convey the impression that they are mature, responsible human
beings.

       Sysops may choose to promote responsible use of the network
by   asking users to make their network posts conform to certain
suggested   guidelines.  For example, the Sysop may request that
users:

       o    Not Use Foul language on the network
       o    Not make personal attacks against others
       o    Not post a lot of one-line messages on the network
       o    Learn the differences between using A, W, or P to respond to
network messages.

       These are merely suggestions for responsible use of the
network and are not requirements; however, some of those
suggestions are also found in the rules of the hosts of many
network subs.  Where they reflect the host rules, they are network
rules for that sub.


  6. INSTALLATION

       This section of the WWIVnet Docs takes you step-by-step
through the installation process involved in getting set up on
WWIVnet.


  6.1. Apply for Network Node Number

       The first step is to apply to your Area Coordinator for your
node number.  If you have no Area Coordinator, you may apply to
your group   coordinator who, in the absence of an area coordinator, will
check out the viability of your board and assign you a node number.
Appendix H gives details on determining who your AC is.



  6.2. Being Checked Out

       The AC or GC who checks out your node will be concerned with
making a judgement to determine if your board a viable, stable
board.  This basically is done to determine that it works okay,
answers the phone, etc.

       Although part-time boards are permitted on the network if
they are   deemed to be stable, are end nodes, and are accepted by
the AC, the AC may decide to not permit part-time boards.  All
unregistered boards will be dead-end nodes (ie, limited to one
network connection).

  6.3. Node Number Assigned

       Once your board has been checked out by the AC or GC and
found to be acceptable according to the criteria discussed above,
you will be assigned a node number.  Node numbers are based on area
codes according to the following numbering system.  An area code
with a 0 in the middle, will use the first and last digit of the
area code followed by numbers from 00-49.  Area codes with a 1 in
the middle will use the first and last digit of the area code
followed by numbers from 50-99.  For example, a board in the 502
area code would be assigned a number between 5200 and 5249.  A
board in the 512 area code would be assigned a number between 5250
and 5299.  As the number of systems within each group grows, this
numbering system may be subject to change.

       Once you have been assigned a Node number, you should enter
this into your INIT with option 2.  The result for system 5256,
for example, is:

                 System number    : 5256
                 Net low time     : 03:00
                 Net high time    : 05:00

       The system number is entered as shown.  Whether or not you
choose to have a net low and high time is optional and will be
discussed later.    Also, in INIT option 1, you should insure that
your board name and telephone number are entered exactly as they
are shown in the BBSLIST.### file which is also discussed later.

       Before assigning you a node number, the AC or GC will find
out whom   you wish to connect with.  They are not responsible for
obtaining network connections for you although they will probably
have some good suggestions as to whom you might connect with.  The
connections will be displayed in the CONNECT.### file which you
will receive as part of network updates from the Group Coordinator.


  6.4. CALLOUT.NET

       You will have a CALLOUT.NET file which should be placed in
your DATA directory and which will show the systems which you
connect with. This file is in the following format:

  @node [macro options] [transmit options] [callout options]
[password]

       Each of these options is discussed in turn.  The node is the
node number of the board you are connecting with.





  6.4.1. Macros:

       Macros are often used in WWIVnet to achieve special
purposes.    These purposes include (a) connecting with another
board in your area code where it is necessary to dial 1 before
dialing the board number, (b) using a telephone service such as
PcPursuit where special numbers, passwords, etc., must be sent, (c)
connecting with another board that is running WWIVnet as some form
of door (i.e., WWIV is not answering the phone--instead some other
software answers).

       The macro to use is designated in the CALLOUT.NET by %x
where x is an integer number.  The macro should then be provided
in the DATA directory under the name Mx.NET where x is the same
number.

       For example, if you use PcPursuit to call St. Louis, Mo.,
and   Phoenix, Az. you would need a macro for each city.  The macro
commands and a sample PcPursuit Macro are in Appendix A of this
document.


  6.4.2. Transmit Options:

       Transmit options are basically two.  You may use the &
parameter   which means that files will be transferred each
direction when a connection takes place.  If the & is omitted then
the transfer will be uni-directional; from you to the other board.
In such a situation, you pay to send your files to the other board,
and presumably, it will pay to send its files to you.  This is not
a very efficient arrangement and is basically discouraged.

       The other transmit option is for network compression.  If
you   specify the ; parameter, then network traffic to be
transmitted to that   node will be compressed, using implode
compression technique.  PKzip or other compression programs are
not needed, as the compression/decompression code is built into the
network software (using the PkZip data compression library).  You
must ensure, however, that the system for which you specify
compression is using net24 or higher; if they are using net23 or
lower, all compressed data sent to that node will be lost.

       Please do not assume that compression should be used for all
your net connections.  Local connections and high speed
connections that also   use V.42bis are probably not good choices
for using compression.  Also, try to avoid using MNP5 on
connections for which compressed data is sent.  The packets that
are created begin with z.  For example,

       Z5252.NET

would indicate a compressed net packet bound for node 5252.  You
should check with the Sysop of the other node before enabling
compression between your system and the other.  Some
experimentation may be necessary to determine which connections
benefit from compression.


  6.4.3. Callout options:

       These options affect when your board will call the other
board.

       /x   Where x is an integer between one and 9.
This means that the network will force a callout to that board every x
days, even if there is no mail waiting to be sent to that system.  This
parameter is often set where one board does not often call the other.

       =    This means to call during PcPursuit hours (6 pm to 6 am
Monday thru Friday and anytime on weekends).  These parameters are
handy for those long distance connections utilizing PcPursuit.
For a board to make use of PcPursuit for the network, a macro
must be used (see appendix for a sample macro).

       -    The minus parameter means to call during times when
rates are  cheapest (11 pm to 7 am and anytime on weekends).  This
parameter is recommended for long distance connections in order to minimize
your phone bill.

       !    This limits the number of calls per day to 1.  The
board will attempt to call out starting 20 hours after the last
successful connect.  This feature only works with WWIV v4.12
or higher.

       !x   Where x is an integer.  This limits the number of calls
per day to no more than x.  The board will attempt to call out
every 20/x hours after the last connect.  This feature only works
with WWIV v4.12 or higher.
       +    The plus parameter indicates that your board does not
call the indicated node; instead, that node should be calling you.
If both of you have the + parameter in CALLOUT.NET then no
transfers will take place between you.

       ~    The tilde (~) means that your system will never call
out to the other system, and that the other system will never call
yours to pick up mail.  The other system will only call yours
to send data to you.

       ^    The caret (^) is used to enable the HSLINK protocol
between your system and another.  If present on both systems (and
the HSLINK executable is found on both systems), the network will
attempt to use HSLINK as the protocol instead of Zmodem (or
ymodem).  CAUTION: Be sure you do NOT have the -! modifier in your
HSLINK.CFG file. NET32 now appends that modifier to the command
line for outgoing Net calls.  If the -! is present in the
HSLINK.CFG file, it may cause conflicts that could prevent
optimiun performance when recieving Net calls.  See Appendix for
details on setting up HS/Link for WWIV.






       Another set of parameters may be used to designate that the
board should call between certain hours.  These parameters are
illustrated   below:

       (3 )5     would mean that the board should call between 3 am
and 5 am.  Times are specified in 24 hour time.  Midnight is
specified as 0.
       These parameters are useful if you are having a connection
with a board that runs a NET TIME PERIOD or to insure that local
connections take place during non-busy hours.  If none of these
time delimiting parameters are used, your board will make the
connection with the other anytime that there is mail to go out and
the board is not busy.  This is NOT recommended for long distance
connections unless you are using a WATTS line or other system that
makes long distance a fixed cost.  It may be used for local
connections if desired.


  6.4.4. Passwords:

       You should not enter a password in your CALLOUT.NET.  The
network software will generate a password between the two systems
once there is a successful connection.  This is one way that you
can tell whether or not your system has successfully connected with
the other.  If there is a password present, there has been a
successful connection.  For more information on passwords, see the
section on Trouble Shooting NetWork Connections.  Also note that
the password will be in quotation marks as the last item on each
line of CALLOUT.NET.


  6.5. Network Software

       You should obtain the latest version of the Network software
and place the files in the main directory of your BBS.  That will
be the directory where the BBS.EXE file resides.  You may determine
the latest version of the software, by asking your AC or GC who
should be able to supply you with a copy of it.  You should remain
alert for changes in the network version.  Currently, it is NET31;
however, future versions will be released as needed.  It is your
responsibility to obtain these versions once you are on the
network.  You may usually obtain them from Amber (Wayne Bell's
board which is @1 in the network), from the WWIV Support Boards
(you will get a list of these with the WWIV software, and the list
is updated from time to time), from your AC or GC.


  6.6. Waiting and Patience:

       At this point, you have done all that you need to do except
 exercise patience.  Your AC or GC will process your application
and arrange for your board to be listed in the appropriate files
which are supplemental to the network.  These files will be in the
data directory, and their functions are as follows.

       BBSLIST.0 - This contains the numbers of valid groups in the
network.  It will look like an N*.NET file, sort of.  All systems
in the network will have a copy of this file.

       BBSLIST.xxx - This file will have a number in the place of
xxx.    The number will be the group number and the file will have
all of the BBSLIST.NET entries for your group.  All systems will
have a BBSLIST.1-255 for all groups listed in BBSLIST.0.  However,
the information in the file will pertain only to that group.

       CONNECT.0 - This file will exist on all systems and will
show  connections between systems in different groups.  For
example, if area codes 512 and 502 are part of the same group
(group 4), a connection between boards in those groups is not
between groups, even though it is long distance, and the connection
would not be shown in the connect.0   file (it would be shown in
the connect.4 file).  However, a connection between 512 and 213
which are in different groups would be shown in the connect.0 file.  Note
that systems with connections listed in the connect.0 file
will almost certainly also have connections listed in their local
connection file also.

       CONNECT.xxx - This file will exist on all systems and will
show connections between systems within that group.  This will not
show connections to systems in other groups.

       If your connection within the group will be calling you,
then you need only wait until you receive the files.  That is, the
AC will turn in your application to the GC who will transmit it to
Wayne.  The GC will also create a new CONNECT and BBSLIST file for
the area which is transmitted to Wayne to be included in future
updates.  Thus, once this update arrives at the board which will be
calling you, that board will callout to you and you will receive
the necessary files.
       If you are to call the other board (and it does not call
you), then you will need to keep in touch with that sysop so that
you have an idea of when the network update comes in.  When it
does, you will need to have your AC put the current bbslist.* and
connect.* files in an archive so you can download them.  Put these
files in your DATA directory and execute "NETWORK3 Y" from your
main BBS directory.

       Although it is natural for you to want to begin to subscribe
to subs and so forth, you should exercise patience until you are
'officially' in the network.  If you order subs before your board
is official, then your system will show up as "unknown" and the
mail will not reach you.  Since many hosts of subs like to send new
subscribers the rules regarding posting on that sub, the fact that
you are an unknown system may result in a delay in your receiving
the sub.  If you wait until you are officially in the network, then
these problems are avoided.

  6.7. The Area Coordinator (AC)

       The area coordinator (if there are more than 5 boards in the
area code) has the responsibility for processing your application
to the network.  He will need the following information:

       Your Board Name -- exactly as you want it to appear in the
Network.  You may wish to peruse a current listing of boards on the
network in order to select a name that is unique.

       Your telephone  -- this should include both area code and
complete number.

       Maximum Baud -- this should be the maximum baud rate that
you can support.  If you are using a high speed modem capable of
more than 2400 bps then you should indicate the rate that your
serial port is locked at as the maximum baud rate.  Also, if you
are using a high speed modem, the AC will need the modem type.

       The information above will be included in the BBSLIST.XXX
for your group along with a group identification number.  In that
listing, AC's are designated by a ^ next to the telephone number.
This information will be transmitted by the AC to the Group
Coordinator.  It is also necessary to inform the AC of whom you
will connect with.

  6.8. The Group Coordinator (GC)

       The group Coordinator, upon receiving information for a new
 addition from an AC will put the information for bbslist into a
file BBSLIST.XXX where the xxx is equal to 256 + the group number.
For example, for group 5, this file would be BBSLIST.261.  This
information along with a CONNECT.xxx of the same number will be
transmitted to 1 @1 who will update all master lists.  The program
that the Group Coordinator uses to send these updates to Wayne will
be written by Wayne and provided to them.  This insures the
integrity of the network and will prevent 'rogue' groups from
entering the network.  If a Group Coordinator makes an error in his
net update information, it will only affect his group.  Thus
problems can be isolated.


  6.9. Net Editor

       Black Dragon (1@2380) developed the Net Editor to facilitate
the updating of network files by sysops and Area Coordinators.
That program is fully compatible with all network data structures
since the beginning of WWIVNet to the present.




  7. USING THE NETWORK

       Using the network is relatively simple.  Sending netmail,
subscribing to network subs and hosting network subs are discussed
in this section.


  7.1. Sending Netmail

       Netmail is like email on your local system.  That is, users
on your board may send email to one another by entering either the
name or user number of the person that the mail is to be sent to.
In netmail, you must also use the node number as part of the
addressing scheme.  Suppose that user number 5 on your system
wishes to send netmail to user 2 (KatyDid) at 3451.  In that case,
the netmail could be addressed as follows:

       2 @3451
        -or-
       KATYDID @3451

Please note that this is merely an example; there is no user named
KATYDID @3451.  Also, this form of addressing will not work for
mail to be sent from one network to another.  Inter-network
addressing under NET32 is discussed later.

       Such mail may be sent by the user in one of several ways.
The user could simply use the E option to send email and then
address it properly.  The user might use the A response to send a
private message to someone who has posted on a national message
base, or the user might use either the A or S to respond to a
message received privately from another system.  Any of these
methods will result in netmail being sent to another system.

        Mail may also be sent from one WWIV-based NetWork to
another by using the following type of addressing:

NETWORK NAME UserNumber AT NodeNumber @XXXX where XXXX is the
gateway node number.  For example to send mail from WWIVlink to
user #1 at node number 1 on WWIVnet, the mail would be addressed as
follows:
WWIVNET 1 AT 1 @5252

That is just an example.  Any node that is running the NET32
software can function as a gateway node provided that it has
connections in both networks.



  7.2. Subscribing to a Netted Sub

       The method of subscribing to a networked message base
depends upon the version of NETxx that you are using.  To subscribe
to a message base hosted by another system (i.e., a netted sub)
while using NET30 or earlier, there are 3 things which you must do.  First,
you should send netmail to the host of the sub requesting
that she place you on the distribution list for that sub.  It is a
good idea to name the sub and sub-type in that letter as many
people host more than one netted sub and it will prevent them from
getting confused.  Second, you should enter your DATA directory and
create a file.  The name of the file should be NNsub-type.NET and
it should have the host's node number in it.   Although you can do
this with an ascii text editor, it may be easiest to do this from
the DOS level with the copy con command.  To accomplish this, type
in the following (note information beginning with -- is
commentary and should not be typed) assuming that you are
subscribing to  the WWIV New Sysop's sub (sub-type 5253; hosted by
5252):


  copy con NN5253.NET      --followed by an ENTER or RETURN   5252
F6 --the F6 means press Function key 6 or you can hold control down
and press Z.

       A successful result will result in the message "One file
copied" being seen on your screen.  Please be sure to put two N's
in the NNxxxx.net file.  One N is used for a host system, so if you
put a file  with one N into your data directory, it will result in
messages being doubled, most disconcerting to the host and other
systems which subscribe to that sub.
       Starting with WWIV v4.20 rev D and ending with NET31, there
is an alternative to having many little nn*.net files in your DATA
directory.  You can list all the subs you subscribe to in the file
'NNALL.NET' in your DATA directory. Each line in the NNALL.NET file
contains the information for one subboard.  The first number on the
line is the sub type, and the second number is the host system.
Anything after that is a comment.  For example, you might have the
following lines:

  1701      1         Star Trek sub
  10001     1         Politics sub
  5253      5252      WWIV New Sysop's sub

       Note that you >MUST< be using WWIV v4.20 rev D or later for
this to work.
        Starting with NET29, it was possible to auto-request a sub.  This
meant that if the sysop had listed the sub in a file called
ALLOW.NET in DATA, the the subscriber/sysop could automatically
request the sub.  This method has been further refined under NET32
and v4.22 of WWIV so that the ALLOW.NET is not used and the
NNALL.NET is not used either.  SUBS.DAT contains all of the
pertinent information regarding the sub and the networks that it is
on.

       The third step is to either use B (for boardedit) when you
are at  W-F-C or type //boardedit when you are logged onto your BBS
and then set up the message base.  Be sure to indicate the sub-type
number in the option for that: Completed result for the New Sysop's
Sub might look like the following under v4.22 :


  A. Name       : WWIV New Sysop's Forum
  B. Filename   : NEWSYS
  C. Key        : None
  D. Read SL    : 60
  E. Post SL    : 60
  F. Anony      : No.
  G. Min. Age   : 0
  H. Max Msgs   : 50
  I. AR         : C
  J. Net Info   :
         Network     Type   Host    Flags
      a) WWIVNet     5253   5252
  K. Storage typ: 2
  L. NetValidate:  No
  M. Require Ansi:  No
  N. Disable Tag:  No
  O. Description:  WWIV New Sysop's Forum for Help & Advice on WWIV

       Since the host of New Sysop's Forum permits visiting sysops
to read and post and since the sysop of this board assigns an SL of 60 and
an AR of C to visiting WWIV sysops, he can be sure that the host's
requirements are met.
       Although you are not required to do so, it is a good idea to
send a short thank you or other acknowledgement to the host to
let him know when you begin to successfully receive messages on
the sub.  If the host has special rules and regulations that you
need to inform your users of, you may do this in several ways.
You could include such information in a form message (i.e., a
message named FORMxx.MSG where the xx may be either integers or letters)
which you send to all users.  You also might make the first message on the
message base contain the rules and then make it a permanent message.  If
you choose this form, be sure to make   such a message before you get
hooked up to receive the messages, else your message will go out on the
network.  Finally, you could put a synopsis of special rules in the GFILES
area and direct your users to read that.



  7.3. Hosting a Netted Sub

       As part of the network, you will receive SUBS.LST, a listing
to be found in your DATA directory regarding the various networked subs
that are available for you to subscribe to.  At some point, you may wish to
 host a netted sub yourself.  If you do, you should first make sure that
there is not another sub already out there serving the same need.  If
there is, then you should only host a sub on the same topic because you
think that you can do it better or because yours will have a special
slant. On the other hand, you may have expertise in an area or information
on a subject which is not being currently addressed on the WWIVnet and for
which you think that there might be a demand.  In that case, you could
decide to host such a sub.

       To host a sub, you must create an Nsub-type.NET file in DATA
and in it, you should keep a list of the systems which subscribe.  The list
may be vertical or horizontal as long as there is a space between numbers
when they are placed horizontally.  Personally, I recommend a vertical
listing from lowest to highest; that way you can easily tell when a sub
has already subscribed.  The traditional numbering of subs would start
with your node number.  For example, assume that you were node 5290,   then
your logical sub numbers would be:

       Hosted Sub     Sub-type       Host

       First           5290          5290
       Second         15290          5290
       Third          25290          5290
       Fourth         35290          5290
       Fifth          45290          5290
       Sixth          55290          5290

       You may observe, however, that not all subs in the network
are numbered this way.  This is because of two occurrences.
First, many boards hosted subs before this numbering system was
developed.  Secondly, sometimes the original host ceases to sponsor a sub
and  another sysop takes it over but maintains the original numbering
scheme.    For example, Sub-type 2370 is the number of the WWIV
Modifications Net Sub which started in 1988 at the White Star Line.  After
Will Daystrom,   the originator, no longer could host the sub, it was
passed to others.    Although the host number changed, the sub-type
originally used continued to be used.

      Net32 and V4.22 of WWIV support a Sub-by-Name concept which means
that you may use any legal 7 letters or characters as a SubType.  This
numbering convention will enable boards to handle more subs than were
possible before under the sub-as-integer concept.

       You may want to develop a form message to send to those sysops who
subscribe to your sub.  Such a message should remind them of the name,
sub-type, and host and it should provide any rules that you may have
regarding who may access the sub or who may read/post there.  Also you
should get in the habit of reading your mail regularly and responding
quickly to requests for the sub.
       You may wish to advertise your sub.  There are some National
netted subs which have been developed just for that purpose and you should
use them if you can.

       The host has the right to run his sub as he sees fit and may
establish any rules he wishes.  The only restriction on sub topics
is that they be legal.  If a host chooses to 'throw' someone off
of a sub,   the individual has no recourse.  Of course someone may
start her own sub if she wishes.


      WWIV v4.12 and following introduced a feature known as Net
Validation.  This feature may be toggled on or off in BOARDEDIT.
When it is toggled on, messages will not leave your system until
they have been validated.  A host, when reading new messages on
a sub, may press X to prevent a message from being sent out.
After reading the messages, she will be asked, "Net Validate
these Messages?"  A Y response will result in all messages being
sent out except those where an X was pressed.  After all messages
have been read, pressing X will cause them to be sent again.
NOTE: This should not be done for it may result in sending out
duplicate messages across the network.


  8. NETWORK FILES

       The files discussed below are the Network executable files
which should be placed in the same directory as your BBS.EXE
file.  The files which belong in your DATA directory have already
been discussed in a previous section of these docs.

       1)   NETWORK.EXE - This file is run when a BBS is calling
another board through the network.  This program handles the modem and
the network security.

       2)   NETWORK1.EXE - This program analyzes P*.NET files to
determine which are for local distribution and which are to be sent to
boards that you connect with.  The latter files will be stored in DATA in
Sxxxx.NET files where xxxx is the node number of the receiving board, or in
Zxxxx.NET files if the packet is compressed.

       3)   NETWORK2.EXE - This program analyzes local mail and
distributes it to the proper message sub or to email.

       4)   NETWORK3.EXE - This program analyzes CONNECT.NET and
BBSLIST.NET. The analysis may cause WWIVnet to leave you messages.  The
sysop should read these messages and respond to them ASAP.  These messages
are discussed in Appendix B.
       5)   LNET.EXE - This program allows the deletion of corrupted
messages prior to their being sent over the network.  It can also be used
to delete a message which the Sysop does not want to go out over the
network....such as one which violates the spirit or rules of a Sub.  As a
general rule, a Sysop should not use LNET to read outgoing messages.  One
exception to this is to use LNET to read the messages in DEAD.NET.  LNET
cannot read mail in packets which have been compressed.

            DEAD.NET is a file to be found in DATA for messages
that could not be delivered because the system and/or routing was in
error.  The header for these messages in DEAD.NET indicates the systems
which it is for and the number of days since it was written.  Sometimes
messages go there because a new board has not gotten set up yet; but often
they go there because one or more of the destination boards have gone down.
If these messages are several weeks old, there is probably no harm in
deleting the DEAD.NET.

       6)   DE1.EXE - This program analyzes net packets to make certain
that it is authentic.  Such packets are referred to as Source Verified
messages.

       7)   DExxx.EXE - This program authenticates updates received
from the group coordinator.

       8)   NETINIT.C - This file needs to be used only if you have
registered WWIV and have modified the structure or size of the
userrec structure.  If you have modified it, compile and run NETINIT and it
will store information necessary for the network in the CONFIG.DAT file.

       Additional files may be added to the network as the development
progresses or some of the existing files may be changed and/or
eliminated.


  9. TROUBLE-SHOOTING NETWORK CONNECTIONS

       Utilizing the NETWORK is really very simple.  If you have tried
everything you can think of to remedy a problem and are unable to do so,
contact one of the Sysops of a SUPPORT Board and enlist aid.    Do not
contact WAYNE BELL except as a last resort.  Sometimes there are   problems
with the code and/or its compatibility with different modems; however,
those type of problems can only be addressed after all other avenues have
been thoroughly explored, and even then that may not be the solution.  For
example, many WWIV Sysops have registered the WWIV software, obtained the
source code and made extensive modifications to the BBS.EXE.  In that
event, it may be a modification that is causing the problem rather than the
network software.

       When seeking help, be prepared to provide information on your
system, your modem, the error messages you get and so forth.  Debugging
network problems is usually a process of eliminating the various possible
sources of problems one by one.  Any information which you can provide to
speed this process makes it easier on all concerned.

       A few common problems, and their solutions, are described
next.



  9.1. You force callout and the cursor returns to WFC

       First, be sure that you are attempting to force the call
during any   agreed upon hours.  If it is not during the agreed
upon hours, the network software will prompt you "Are you sure?"
An affirmative response will allow the call to proceed.  If the call does
not connect,   you should double check the CALLOUT.NET, CONNECT.0, and
BBSLIST.x to be sure that no typographical errors were made.  Zeros cannot
be o's, group designators must be correct, etc.

       Also, under Net20 and later (with new net organization) you should
ensure that all files in your DATA directory are correct as they affect
your board and the board that you connect with.

       If no typographical errors were made, run network3.exe from
DOS level and force a reanalysis.  If after doing all of these
things, the board will still not call out, go to DATA and delete
BBSDATA.NET, BBSDATA.IND, and BBSDATA.ROU as well as CONTACT.NET
and rerun the NETWORK3 program which will force the reestablishment of the
deleted files.  This will often cure the problem.  If it does not, contact
one of the support boards and explain your problem in full detail.   The
command line NETWORK3 Y will force local feedback to be sent to you from
WWIVnet.  The resulting information may be useful in determining problems
in your network setup.




  9.2. Your board calls out and gets a "Bad PW" message
  The "Bad Password" message will show up in your net log which is
 readable from WFC by pressing N.  If that is the case and a successful
connection has never been made, then the remote sysop should ascertain
that the CALLOUT.NET is correct.  If so, then check the CONNECT.x and
BBSLIST.x.  If a successful connection has been made in the past and a
password between the two boards has been established, then try again as
line noise may be the culprit.  If the "Wrong Password" persists over
several tries, then it is possible that a file has become corrupted.  In
this event, both you and the remote sysop need to delete the password
which was generated by the network and let the net software reestablish
the password.  If you have never successfully connected with the other
board, then the error may be due to the other sysop's not having setup
for the connection.  You should contact him and ascertain whether or not
the connection if reflected in his CONNECT.xxx file or CALLOUT.NET
file.

  9.3. Your board calls and gets a "NO NET" message
       This occurs when an unsuccessful connection occurred.  Often
it is only because the other board is busy.  The remedy is to try
again.  If the board is a new board and you know it is not busy,
then both you and the other sysop should make certain that all
files are in the proper places.  There are several Binary files
created by the network.  These are CONTACT.NET and BBSDATA.*.
Sometimes these files will become corrupted and this may be the
cause of a failure to establish a connection.  You may delete
these two files from the DATA directory and then run NETWORK3.EXE
again.  This re-analysis will recreate those two files and may
cure the problem.


  10. FUTURE DIRECTIONS


       In the near future, WWIVnet is likely to see the following
events   take place although not necessarily in this order:

       REMOTE access by boards or users as a Sysop Selectable
option  OFF-LINE READER for users to download message bases,
read and reply while off-line and then upload responses.

       Increased INTER-NetWorking among established networks.

       Some of these developments will be due to the direct efforts
of Wayne Bell and others will be due to the efforts of programmers and
others who are dedicated to making WWIVnet the finest network available.

       If you have questions about anything in these documents, you
should first ask your AC or GC for explanation or help.  If they
do not know the answers, then contact Filo (1 @2050), and only as
a last resort   contact Wayne Bell (1 @1).

       Because WWIVnet is dynamic, growing, and constantly improving,
these docs will be updated from time to time.

       This document does not address any of the inter-networking
 information that might be necessary to establish your WWIV as say
a FidoNet node.  For information on these other networks, you
should contact the FidoNet/WWIVnet Coordinator (listed in the WWIVnet
analysis feedback.  That individual assigns 'fake' node numbers to
WWIVnet/FidoNet boards.  Currently there is a network support sub for such
interfacing software to other Networks hosted by 1 @7400.

      AC's and GC's are encouraged to subscribe to the AC/GC Sub
(See the subs.lst file for the host system and sub type), and GC's are
expected to subscribe to Random's GC Sub hosted by 1 @1.

       Sysops should check with their GC's to see if there is a
Group sub which they may or should subscribe to.


  11. APPENDICES


  11.1. Appendix A - PcPursuit Macro

  DEBUG ""                       {enables you to see what happens}
  SPEED "2400"                    {speed you are calling at
  DIAL "686-2452"                {put your local PcPursuit Access #
TIMEOUT "7"
  SEND "~@~D~{~D3{"
  WAITFOR "@"
  send "~D~{"
  waitfor "NOT"
  send "~D~{"
  waitfor "NOT"
  SEND "~C D/MOSLO/24,password,idnum{"  {each city has its own code
  TIMEOUT "7"
  FAILURE "D/MOSLO/24 BUSY"
  SUCCESS "ANSWER TONE"
  WAITFOR "D/MOSLO/24 CONNECT"
  SEND "~I{"
  SEND "~ATZ{"
  WAITFOR "OK"
  SEND "ALT 5{"                        {see comment below
  WAITFOR "HELLO"
  TIMEOUT "30"
  DEBUG ""
  SEND "D%2{"
  WAITFOR "DIALING"
  FAILURE "BUSY"
  WAITFOR "ANSWER"


      The ALT 5 character referred to above can be made with an
ascii editor capable of using extended ascii symbols.  The actual
symbol looks like the Club suit in a deck of cards, "the puppy
track".  You can make this character by holding the alt key down,
pressing a 5 on the number pad and releasing the ALT key.

       The macro above has been used successfully for PcPursuit
connections. The comments on the right side after the left brace
({)   should not be typed; they are only partial explanations to
help you   understand what the macro is doing.  Note that each SEND
line ends with a left brace.  In the MACRO script language this
signals a carriage return.  In PcPursuit, each pursuitable city
has a city code.  In the example above, MOSLOW is St. Louis,
Missouri.  You would need a macro for each city that you call.
The %2 in SEND "ATDT%2" is the 7 digit phone number which the
macro will take from the BBSLIST data.



       In conjunction with DIAL or SEND, you may use %1 for the
area code and %2 for the 7 digit telephone number.  If you use
DIAL, you do not   need to use the ATDT command; but with SEND you
need it.

       Using the simple script language contained above, you can develop
elaborate scripts.  In our area, we have written scripts that logged the
network onto QBBS and RBBS boards and selected Door programs which were
WWIV setups which in turn ran the network.

       If you have trouble developing the scripts to use for a particular
application, you should be able to get help from any Support Board.  You
will need a text file taken from a screen capture of what you are logging
into.  Then the support board should be able to help you develop the
appropriate script for you to use.


  11.2. Appendix B - Network message types

       The network recognizes various types of major and minor type
messages, and these are often reflected during the analysis which
takes place after a network message is received.  The information
which follows briefly explains each of these message types.
These types may be expanded in the future.

  Major type 1 - net info
       minor type 0 = feedback to all sysops, from 1@1
       minor type 1 = new bbslist.net - obsolete as of 07/29/90
       minor type 2 = new connect.net - obsolete as of 07/29/90
minor type 3 = new subs.lst (replaced by major type 9)               minor
type 4 = WWIV news.

  major type 2 - email by user number
       (minor type not used)

  major type 3 - post, sent from host to subscriber systems
  minor type = sub type

  major type 4 - file (not used)

  major type 5 - pre-post, sent from subscriber to host
       minor type = sub type

  major type 6 - external program net packet
       minor type = destination program identifier
       major type 7 - email by name - name contained in packet
       (minor type not used)

  major type 8 - net edit info.  The exact definitions of these
    messages is described in the Network Editor documentation.
   These messages are ignored if the Network Editor is not installed.


  major type 9 - subs.lst update
       minor type 0 = subs.lst
       minor type x = subs.x (ie, minor type 1 goes to subs.1)
  major type 10 - not used

  major type 11 - group bbslist
       minor type 0 = bbslist.0 file
       minor types 1-255 = group bbslist files sent from NC
       minor types 257-511 = group bbslist updates sent from GC to NC
    minor types 513-767 = partial bbslist updates, sent from NC

  major type 12 - group connect
       minor type 0 = connect.0 file
       minor types 1-255 = group connection files sent from GC

  major type 13 - not used

  major type 14 - group info from GC's
       minor type 0 - mail from GC to all sysops in the group

  major type 15 - short one line responses (so-and-so read your
mail)
  (minor type not used)

  major type 16 - Request to add to a subboard
       minor type = subboard type

  major type 17 - Request to drop a subboard
       minor type = subboard type

  major type 18 - Response to an add request (type 16)
       minor type = subboard type
       (first byte of message is status; 0 is success)

  major type 19 - Response to a drop request (type 17)
       minor type = subboard type
       (first byte of message is status; 0 is success)


  NOTE: all major type 1, 11, 12, and 14 messages are appropriately
source-verified.


  11.3. Appendix C - Network Policy for Illegal Activities

  Mon Oct 15 20:39:31 1990
  RE: WWIVnet

  Nothing illegal (pirating, phreaking, hacking, bank robbing, etc)
shall   be sent over the net.  Violating this is cause for
permanent removal from the network.  This has ALWAYS been the policy, I
just felt I should re-iterate it, in case anyone has forgotten.  Now comes
the new part:   what happens locally on a system (that does not affect the
network) is the business of that sysop, and is not an issue for the
network.
  I am not advocating or approving of illegal acts.  I am merely stating
that what a sysop has on his system is for him to decide.  As long as it
does not affect the network, it is an issue only between that sysop and
the police.  I am saying that AC's or GC's are not responsible for
policing the systems.  That is a job for the police.  AC's and GC's are
volunteer positions (ie, no pay), and I'm sure everyone has better things
to do with their time than to go on a witch hunt for pirated files.
  $F4 1@1



  11.4. Appendix D - Identifiers Used in BBSLIST

  <    USRobotics HST protocol
  >    Hayes V-series protocol
  |    Telebit PEP protocol
  !    V.32 protocol
  $    V.32bis protocol
  /    Compucom 9600 protocol
  ?    Fax modem
  ^    Area code coordinator
  %    Group coordinator
  &    Network Coordinator
  +    Network Server
  =    PCPursuit connection(s)
  \    FidoNet front-end
  _    Dead-end node.


  The identifiers above may be stacked together.  For example,
"<!$" would indicate a U.S. Robotics modem that is v.32 and HST
compatible and supporting v.32bis.  This list will be expanded
from time to time as other hi-speed modems enter the network.


  11.5. Appendix E - Suggestions for Smooth Networking

  CHANGING GROUPS

      Occassionally, an area code may wish to change from one group
to another.  Such a change could be motivated by a realignment of
connections, by a disagreement with a GC, or by some other factor.  In
order for an area code to change groups, good communications must take
place.  Such communications should involve both Group Coordinators and
the Net Coordinator.  The sysops within the area code should agree to


the change and the AC, if there is one, should notify both his
current GC and the GC of the group that the move is to.  The GCs
should also talk with each other and with @1.  The essential thing here is
that everyone understand and agree to the change so that there will be no
surprises and so that the transition may go smoothly.

  VOICE COMMUNICATIONS
      Voice communications are sometimes helpful in solving and/or
preventing various types of network problems.  To this end, it is
recommended that the GC's have each other's phone numbers as well
as the numbers of the AC's within their group.  It may also be
helpful for AC's to have the voice numbers of the boards within
their group.  Such a sharing of voice numbers is NOT essential to
the network and should NOT be treated by anyone as a requirement
for being in the network.  It is merely one method of decreasing
net problems, speeding up solutions, and insuring communication
among those involved.  No one should be offended if someone asks
for a voice number and no one should be offended if a requested
number is not forthcoming.



  TOLERANCE

       Because communications are seldom perfect and because we, as
human beings, are definitely less than perfect, it is likely that
you may take offense at one time or another to something that is
said in the network.    If this happens, you should try to exercise
tolerance toward others and their views and you should also exercise
restraint when responding to others.  Although throwing out a few well-
chosen expletives may make you feel much better, it seldom is the solution
to a network problem.    Instead, thoughtful, polite and courteous
communication is more likely to sway the other person than vulgar shouting.
As a consequence, all  who participate in the network are urged to exercise
tolerance and restraint.



  LEAVING THE NETWORK

       If you decide to leave the network, you should notify your AC or GC
at least three weeks in advance if possible.  You should also write e-
mail to the host of each sub that you subscribe to and request that your
node be deleted from his subscription list (Nxxxx.NET file).  If you host a
sub, you might either make arrangements for someone else to take over being
host and share your subscription list with that person so that the
respective boards may be notified to change the host number in their
NNxxxx.NET files, or you may notify each subscribing board that you are
leaving the network and that no further messages will be forthcoming on
SubType xxxx.  These simple courtesies are designed to help the network
function more smoothly, to permit AC's and GC's to do  their job
appropriately, and to permit the hosts of subs to maintain accurate
subscription lists.  While some people who are leaving the network have
followed the procedure of posting a "goodbye" letter on each sub to which
they subscribe, e-mail is a more effective method of accomplishing your
purpose.  Some network hosts do not read all of the messages on the sub
which they host and may easily miss a posted announcement whereas the
receipt of e-mail is not as easily overlooked.

  11.6. Appendix F - Using the Net Software for Private Networks

       The network software may be used for any legitimate private
network as long as the user understands that the author is under no
obligation to provide the software which distributes network updates and as
long as the functioning of the private network does not interfere in any
way with the functioning of WWIVnet.  The author will assume no
responsibility for insuring the operation of any private networks or any
other network utilizing WWIVnet or WWIV software.  Further, the WWIV
support board Sysops are under no obligation to explain how to set up
and/or operate a private network.  Of course, even for private networks,
in order to continue using the WWIVnet software past the two month trial
period, you must have either registered WWIV, or (for BBS software that
is in no way based on WWIV software) registered the WWIVnet software.
See Section 3 on page 2 for more information on registering the WWIVnet
software.


  11.7. Appendix G - The Process of Becoming a Group Coordinator

       Group Coordinators will be selected by the Net Coordinator.
The NC may appoint a Group Coordinator based on his knowledge of the sysops
in a particular group, or he may ask for applications from interested
persons.  In the latter case, he may choose to (1) ask the opinions (not
votes) of those in the group regarding the applicants, (2) ask the advice
of the former GC, (3) solicit the opinions of the other Group
Coordinators.


       If a GC quits or fails to fulfill his responsibilites, then
he will be replaced.  At that time, if the NC wants applications
from interested persons in the group, he will solicit them.  Sysops should
not send the NC unsolicited applications.


  11.8. Appendix H - Procedure for Joining/Leaving WWIVnet:
Procedure for joining WWIVnet:
  1. First, find out who your AC (or acting AC) is.

          a. If you already know some sysops in your area code,
just ask one of them who your AC is.  If you don't know any other
sysops in your area code, then, from any WWIVnet system, type "//net"
from the main menu, and look for systems in your area code.  Your AC will
be the one identified by the '^' on his system's  line of info.

          b. If there are WWIVnet systems in your area code, but
there is  no AC, then the GC for that area code is the acting AC.  There's
no real easy way to find out who the  GC is, from the net listing, so the
easiest thing to do is to email one of the  sysops in the area code, and
ask them who the GC is.

          c. If there are no WWIVnet systems currently in your area
code, then things become a bit more complicated.  You'll have to
determine which system already in WWIVnet you'll be connecting
with (through arrangements with that sysop).  You then need to
ask that sysop who his GC is.  That person (his GC) is then your
acting AC.

  2. Send email to your AC (or acting AC), through WWIVnet, to user
#1 on the system (or in feedback on his system), telling the AC
that you want to join WWIVnet.  The AC will need some specific
information from you in order to process your request, so you
should include that info in your original email, to avoid having
to send email back and forth to the AC, in order for him to get
the necessary info.  Info you should include is:


          a. Info about your setup (system name, phone #, and modem
info).  Your system name should be 38 chars or less.  Your phone #
should be in the standard AAA-PPP-####.  If you are outside the
USA, and your phone # doesn't fit into that format, you'll have
to make it fit.  Modem info you should include is your max baud
rate, and protocols supported (if >2400 baud).  Specific modem
protocols you should mention are: Telebit PEP, USR HST, Hayes V-series,
V.32, V.32bis, and Compucom.

          b. How long your BBS has been up consistently (in
months).

          c. Your WWIV registration number, or say you are not
registered.

          d. If you have already arranged a connection with a
system already in the network, mention that connection (by their
WWIVnet node number).

  The text file "netapp.frm", included with the network .ZIP file,
can be used to send this info.

  3. The AC (or acting AC) will then process your request.  The AC
should have handled it within 2 weeks.  If it is not possible to
handle it within 2 weeks, the AC will reply to you within the 2
week period indicating that it will take longer, approx how long it will
take, and the reason(s) why.


  4. If everything goes well, the AC will respond within 2 weeks,
telling you:

          a. Your WWIVnet node number.  You should enter this into
the INIT program.

          b. If you did not specify a connection, the AC may
suggest a connection for you.  Or, the AC may say that you'll have to find
your own connection.  For each connection, you'll have to put the
appropriate line in your CALLOUT.NET file.
          c. The AC will also give you a copy of his current
WWIVnet data files, which will be BBSLIST.* and CONNECT.*
from his DATA directory.  You should put these in your
DATA directory.  Or, if you are running NET31 or higher anv v4.21a or
higher, you may put it into a special network directory which you set up in
INIT when establishing multiple networks.

          d. Within a week or two after you've received your info
from the AC, you should get added into the network, and start receiving
mail.


  5. If everything doesn't go well:

          a. If the AC does not respond within 2 weeks, re-send
your mail to him.  It's possible that the mail got lost, or that he's on
vacation, or some other such thing.  If you don't get a reply 2
weeks after that, then contact the GC, give him the same info you mailed
the AC, plus the dates you sent the request to the AC, and say that
you haven't yet received a reply.

          b. For some reason, the AC may determine that you cannot
currently join the network.  In this case, the AC must reply to
you giving the specific reason(s) why you are not being let into
the network, and the circumstances (if any) under which you may
be let into the network, in the future.  The AC will also send a
copy of this letter to the GC.  If you think the reasons given
are not legitimate, then you need to contact the GC, and explain
your case to him.


  II. Leaving the network.
  1. You should notify your AC at least 3 weeks before you leave
the network.  You should give as exact a date for your leaving as
you can.   Additionally, 2 weeks before you leave, remind your AC
that you are leaving.

  2. About one week before you leave, your AC will remove all your
 connections except for one (you may specify which one is to be
left).   On about the date you specified (the next update after
that date), the one remaining connection will be removed, and you
will be dropped from the net data files.


  3. If some emergency arises outside your control, such that you
are unable to give a 3 week warning, you should contact your AC
as soon as possible, and inform him of the situation.

          a. For example, if your hard disk crashes, and you are
unable to afford a new one, or your reserve unit is activated, and you
have to leave for Saudi Arabia tomorrow, you should get ahold of
your AC as soon as possible, so that you can be removed from the
net data files, and cause as little disruption to the rest of the
network as possible.
  4. If you have to leave the network without a 3 week warning, but
it is NOT due to something outside your control (ie, you haven't
been doing   your homework, and your parents take away your computer), you
should STILL notify your AC as soon as possible.
However, do not expect your AC or other sysops to be very happy
with it.  Also, expect the AC to be very hesitant about letting
you back into the network in the future.

  11.9. Appendix I - Automated subboard requests

  Net29 and above support automated subboard subscriptions.  In
order for this to work, BOTH systems (the host and the
subscriber) must be running Net29 or later.  The program
'REQ.EXE' can be used to subscribe or drop  subboards.

  There are some files associated with automated subscription under Net29,
Net30, and Net 31:

  ALLOW.NET (in the DATA directory) - lists subboard types that are
under automated control.  If you host sub type 1701, and you want
systems to be able to automatically subscribe to it, you would
have the number 1701   in the ALLOW.NET file.  If a sub type is not
listed in the file, or the file does not exist, then sysops will
not be able to automatically subscribe to the subboard.

  DISALLOW.NET (in the DATA directory) - lists system numbers that
are NOT allowed to automatically subscribe/drop subboards.  If
you want to keep a certain system from subscribing to any of your
subs, place their   system number in the DISALLOW.NET file.
SA*.NET (in GFILES directory) - This is a text file that is sent,
as part of a pseudo-email, to a sysop when they are added to a
sub.  If you host sub 1701, then the file 'SA1701.NET' would be
appended as part of a piece of mail to the sysop that is
subscribed to the sub.  It can give any rules of the sub, etc.

    SR*.NET (in GFILES directory) - If a system is not allowed to
automatically subscribe to a sub (if the sub isn't listed in the
ALLOW.NET, for example), then this piece of mail is appended to a
message informing the sysop that he cannot be automatically added
to the sub.  The file should list why it isn't under automated
control, and if it would be worth the effort to email the sysop
and ask for it.

  The REQ.EXE program is very simple to use.  You need to know only
if you want to add or drop the subboard, the sub type, and the
host.  You then put all this info on a command-line, such as:

  REQ A 1701 1

  To REQuest an Add to type 1701 hosted by @1.  To drop the sub,
you'd say:

  REQ D 1701 1

  You should get email back from the system when you are automatically
added/dropped from a subboard.  You will get no mail back, and nothing
will happen, if the remote system isn't running net29 or later.  If you
request to be added to a subboard that you don't have configured into
your system (in //boardedit), then when the response comes back
indicating you were added, the network will automatically request
that you be dropped from the subboard (since there is nowhere for
the  messages to go), and you will NOT get an indication in feedback.
11.10  Appendix J - Multi-Networking with NET 31 and v4.21a

     Beginning with NET31 and v4.21a of WWIV it is possible to network
among WWIV-based networks rather easily.  The methodology for doing this is
discussed thoroughly in the documentation for WWIV v4.22.



11.11 -Appendix K - Optimizing HS/LINK for WWIV 4.21+ & NET31+

    The first part of this appendix defines some terms that are used
in the rest of this discussion. The second part discusses ways of
setting up HS/Link to optimize normal WWIV BBS connections. The third
part describes the problems involved using HS/Link on WWIV with PC
Pursuit, and how they can be taken care of. Part 4 deals with
optimizing HS/Link for use with your terminal program, and part 5
deals with how to do Bi-Directional uploads and downloads.


          Part 1 - Definitions:

     BLOCK :
 HS/Link sends data in packets (blocks). Normally each block contains a
unique sequence number and checksum info to aid in data verification
and error detection and recovery.

     BLOCK SIZE (-s) :
Size of each block in bytes.

     CONFIGURATION FILE :
An ASCII file that is used to set HS/Link's options. This file can be
created with HSCONFIG, or with your editor. The default configuration
file is HSLINK.CFG. This is the file that HS/Link looks for if no
other is specified on the command line. To specify another
configuration file start your command line as follows:
"HSLINK -@filename".
Don't type the quotes. The filename is the name of the alternate
configuration file you want HS/Link to use. This MUST be the FIRST option
on the command line.

     CURRENT HS/LINK VERSION :
Be sure to use the LATEST release of HS/Link. While the current
version is always compatible with older versions, you will not get the
benefit of the latest enhancements and fixes if you are using an old
version. At the time of this writing, the latest RELEASE version is
1.12.

     DENY UPLOADS (-NU) :
This option is used for BBS programs that don't know how to handle bi-
directional transfers, or on SEND command lines when when uploads are not
expected or desired. It should be used on the HS/Link command lines in INIT
for SEND and BATCH SEND to insure security.

     DOWNLOAD DIRECTORY (-U) :
This option controls the destination directory for incoming files. By
default, HS/Link will put incoming files into the "current" directory.
This is where WWIV is expecting to find them. WWIV changes to the
'TEMP' directory before recieving files. The BBS will move the files
to where they belong, so the -U option should NOT be used for the BBS.
It may however be used in conjunction with a caller's terminal
program. For Example, -UC:\TEMP in the caller's HSLINK.CFG file would
place the incoming files in his TEMP directory on drive C:.

     FORCE REMOTE TO USE LOCAL OPTIONS (-!)
This option causes the remote (called) end to use some of the options
specified by the calling end. This does NOT affect any of the options
having to do with security, such as the upload path, or the overwrite
option. It does affect block size (-s), xon/xoff (-hx), and windows (-w).
Normally the system PLACING the call turns this option on. It should
be turned off on the receiving end.


     HARDWARE HANDSHAKING - CTS/RTS (default) :
A means of flow control where the modem asserts the CTS (clear to
send) line when it is able to receive data from the computer. If it's
buffer fills up, it drops the CTS line. In the same way, the computer
asserts the RTS (request to send) line when it is able to receive data
from the modem, and drops it if it is busy. This scheme is used by
High Speed modems that can operate with a port speed that is higher
than the connect speed.

     SLOW HANDSHAKE (-hs) :
Sends Xoff or lowers RTS during disk I/O. This causes the computer to
signal the modem not to send any data during disk I/O. It is available
for systems with slow disk access. It may help if you get frequent CRC
errors or COM overruns on clean lines. Be sure NOT to disable Xon/Xoff
handshaking if this option is used.

     UART OPTIMIZATION (-FTx)  VERSIONS 1.13C4 and above only :
This option sets the number of bytes the 16550 UART will buffer before
requesting service from the CPU. The valid settings for x are 1, 4, &
8. One is default, and the most conservative in that it requests
service as soon as a character is recieved, thus allowing up to 14
more to come in while waiting for service, without loosing any.
Increasing this setting may improve thruput. If you encounter COM
OVERRUNS, reduce the setting.

     WINDOW (-w) :
The number of blocks HS/Link will send before stopping and waiting for
an acknowledgment (ACK). If set to 0, HS/Link operates in full
streaming mode (like DSZ). A setting of 4 is recommended for networked
connections like PC Pursuit.

     XON/XOFF (default) :
 A software method of telling the other end to suspend/restart
sending data. It is not generally necessary for error correcting
modems, but no harm is done by leaving it enabled. (Do not disable
this if Slow Handshaking (-hs) is required by your system).


                         INIT settings for HS/Link

          Description              : HS/Link
          Xfer OK code             : 0
          Require MNP/LAPM         : N
          Receive command line:
          HSLINK -P%2 -E%4 -U%3
          Send command line:
          HSLINK -P%2 -E%4 -NU %3
          Receive batch command line:
          HSLINK -P%2 -E%4 -U%3
          Send batch command line:
          HSLINK -P%2 -E%4 -NU @%3
          Bi-directional transfer command line:
          HSLINK -P%2 -E%4 -@ @%3


          Part 2 - Optimizing HS/Link for WWIV BBSs that do NOT make NET
               calls via PCP


      If you operate a WWIV BBS that does NOT make NET callouts via
PCP, then the following HSLINK.CFG file settings and INIT settings
should be optimum for you.

          HSLINK.CFG - use HSCONFIG or wordprocessor to create
       -A        /* don't send ACKs */            << don't type the >>
       -S4096    /* sets 4k blocks */             << comments       >>
       -W0       /* do not wait for ACK /*



          Part 3 - Optimizing HS/Link for WWIV BBSs that make NET calls via
                  PC Pursuit

      The problem with PCP is that being a timeshare net, it does not
transmit data continuously, especially during busy times. There may be
delays in data transmission. If the HS/Link default block size of 1024, or
4096 is used, and the default window of 8 is in effect, HS/link will send 8
of these blocks before stopping for an acknowledgment. If PCP is busy, this
may be more data than it can "swallow" in one gulp. Once PCP gets behind,
it may have problems recovering, in which case the data may or may not get
thru. Even if it does, the ACK may not get back to the sending end, in
which case HS/Link waits for it's internal timeout, before trying again.
Often PCP cannot recover at all, and HS/Link will finally about the
transfer.

     This problem can be resolved by using smaller blocks, and smaller
windows. A setting of 512 or smaller for the block size is recommended, and
a window of 4 should work fine. This will give PCP smaller blocks of data,
and HS/Link will stop more often to check that the data has been received.

     This is the optimum HSLINK.CFG file setup for use with PCP:
         -S512     /* use 512 byte blocks */
          -W4       /* wait for ACK after every 4 blocks */

     NET32 will append the -! option to the HS/Link command line for
outgoing calls, thus forcing the remote to use these settings. Since
it is not present on the command line to incomming calls, the calling
system will be able to use the settings that are best for his lines.



          Part 4 - HS/Link and your terminal program

     The calling party has the responsibility of determining the best
HS/Link configuration options for his/her particular situation (PCP, Non
PCP, etc). You should configure HS/Link for your terminal program, and
include at least the following options in the .CFG file.  Be sure to
include the (-!) on the command line to force the remote to also use your
preferences. If your terminal program will be using a different HSLINK.CFG
file than the BBS, you may include it in that file. DO NOT PUT -! IN THE
HSLINK.CFG FILE YOUR BBS WILL BE USING.

      If you are calling via PCP, then your HS/Link config file should look
like the following one. You should also use PCP's default handshaking:

          -S512     /* use 512 byte blocks */
          -W4       /* wait for ACK after every 4 blocks */
          -UC:\temp /* set to directory you want your downloads to go in /*

     If you use "direct" connections ( regular lines), then your   HS/Link
config file should look like this:

          -A        /* don't send ACKs */
          -S4096    /* sets 4k blocks */
          -W0       /* do not wait for ACK /*
          -UC:\temp /* set this to the directory you want your downloads to
    go in /*

     In the event that you do both PCP and Non PCP calls, you can give one
of these files a different name (ie NON_PCP.CFG), and then on the HS/Link
command line for your Non PCP calls, include the following as the FIRST
option:

          -@NON_PCP.CFG

          Be sure to include the pathname.   ie @C:\TELEX\NON_PCP.CFG


          Part 5 - Bi-Directional file transfers

     For bi-directional transfers to work properly, You must NOT  have a
"Download Directory" set in the HSLINK.CFG file for the BBS !  This is the
option that begins with a -U. If you want uploads to go to the Sysop
directory, you should set that option in INIT. It is ok for the caller to
have the -U option set for his terminal program.

     Here is the procedure for doing bi-directional file
transfers:

          Select (D)ownload
          Enter the file name you want to receive
          Select "Batch" as the protocol
          Repeat for additional files
          Select (U)pload
          Enter the file name and description of the file to be uploaded
          Select "Batch" as the protocol
          Repeat for additional files

          Type X or B to bring up the "Batch" transfer menu
          Select B from the menu    << important. D or U will NOT work >>
          Select HS/Link as the protocol
          Start your HS/Link UPLOAD << download will begin automatically >>


       I hope this takes some of the mystery out of HS/Link operation. Sam
Smith (HS/Link author) has looked this over, and it has his blessings. If
you have any problems, or discover something I have overlooked, or
described incorrectly, PLEASE notify me as soon as  possible. I will
attempt to update this appendix as new information becomes available. (by
Lance Halle  1@6211, 10/13/92)